The present invention relates generally to data processing systems, methods and computer program products and, more particularly, to data processing systems, methods and computer program products for distributed object environments.
The explosive growth of the Web, the increasing popularity of personal computers (PCs) and advances in high-speed network access have brought distributed computing to the forefront. In addition, there is currently interest in distributed objects for object-oriented applications. Various architectures currently exist for accessing objects located within distributed computing environments. One such architecture is the language-neutral Common Object Request Broker Architecture (CORBA). At the core of the CORBA architecture is an Object Request Broker (ORB) that acts as an object bus over which objects transparently interact with other objects located locally or remotely.
Other language-specific models for distributing applications include Distributed Component Object Model (DCOM) and Remote Method Invocation (RMI). DCOM is an object-oriented implementation for distributing ActiveX(copyright) applications (ActiveX(copyright) is a trademark of Microsoft, Redmond, Wash.). RMI is an object-oriented implementation for distributing Java(copyright) applications (Java(copyright) is a trademark of Sun Microsystems, Mountain View, Calif.).
In a distributed object environment, a client application communicates with a remote server application through a xe2x80x9cserver stubxe2x80x9d located on the machine (computer) hosting the client application. The stub is obtained from a remote object registry (i.e., a naming service). Remote object registries are well known to those skilled in this art. Typically, a registry is located on the computer hosting the server application and is referred to as a xe2x80x9cserver-sidexe2x80x9d registry. In a distributed object environment, a single server application may typically support multiple client applications. However, a server application must generally be started with an associated stub registered in the server-side registry, before a client application can access the server application.
FIG. 1 schematically illustrates a client application 10, resident within a computer 11, communicating with a server application 14 located on a remote computer 12 hosting one or more server applications. In FIG. 1, the client application 10 wants to communicate with a server application named xe2x80x9cMyAppxe2x80x9d 14 located on the remote computer 12. Upon initially starting up, the application xe2x80x9cMyAppxe2x80x9d 14 registered itself with the server-side registry 16 as illustrated. In the illustrated server-side registry 16, the application xe2x80x9cMyAppxe2x80x9d 14 has identifier (also referred to as a name or key) xe2x80x9cMyAppxe2x80x9d and the stub xe2x80x9cAppStubxe2x80x9d. To communicate with the xe2x80x9cMyAppxe2x80x9d application 14, the client application 10 obtains the server stub 18 for the xe2x80x9cMyAppxe2x80x9d application 14 from the server-side registry 16. As is understood by those skilled in this art, client application requests to a server application are made using a server stub associated with the server application and that is obtained from the computer hosting the server application. A server stub 18 communicates with an associated server application via a server skeleton 19, as is known to those skilled in this art.
Based on the operating platform of a server application, it may be desirable to run the server application in a user""s address space. Instead of running a single instance of the server application in a shared address space, each user would run an instance of the server application in a private (user) address space. In some multi-user systems, such as IBM""s Multiple Virtual Storage (MVS) systems, running instances of a server application within user address spaces may be required to achieve an acceptable level of protection, security and user authentication.
However, running an instance of a server application in a user address space generally means that user address space creation, server application startup and registration with a server-side registry cannot occur until a user performs xe2x80x9cloginxe2x80x9d procedures with a computer hosting the server application. Unfortunately, after initiating login procedures with the hosting computer, and requesting that a server application be started, there may not be an automatic notification back to the requesting client application that the server application is started and ready to serve client requests. For example, in FIG. 1, if the server application xe2x80x9cMyAppxe2x80x9d 14 is not already running when the client application 10 makes a request to the server application xe2x80x9cMyAppxe2x80x9d 14, the client application may not be aware of when the server application xe2x80x9cMyAppxe2x80x9d 14 is ready to accept requests.
A possible solution to the problem of knowing when a server application is active involves allowing client applications to poll a server-side registry until a valid server stub associated with a server application is returned. Unfortunately, polling is generally not an acceptable solution, particularly in a distributed object environment, because of the complexities polling adds to client applications and because of increases in network traffic.
Other issues of concern with the use of server-side registries relate to reliability, security and object naming. A server-side registry may provide a single point of failure. For example, if a server-side registry terminates abnormally, client applications may be unable to make requests to server applications. Although multiple server-side registries may be utilized to overcome this limitation, multiple server-side registries are generally not desirable because of the administrative complexities involved.
A server-side registry typically provides an application programming interface (API) that allows a client application to query objects registered within the registry. From a security standpoint, a rogue client application could access a server application via a server-side registry API without having permission.
Another drawback of server-side registries is that a client application generally needs to know the name of a registered server stub associated with a particular server application. In an environment of a single computer hosting multiple server applications, wherein each server application registers its own server stub, care must be taken to ensure that server objects are registered with unique names. Each client application accessing a server application needs to be aware of what naming scheme is being used and of any changes to existing naming schemes.
In view of the above discussion, it is an object of the present invention to allow client applications to know when a server application is ready to receive client application requests without requiring polling.
It is another object of the present invention to reduce processing disruptions between a server application and multiple client applications because of a server-side registry failure.
It is another object of the present invention to enhance security with respect to objects within a distributed object environment.
It is another object of the present invention to reduce naming complexities involved in a distributed object environment including multiple computers hosting server applications.
These and other objects of the present invention are provided by systems, methods and computer program products for invoking a server application resident on a first computer to handle requests from a client application resident on a second computer, remote from the first computer, using a client-side remote object registry. According to the client-side perspective of the present invention, the first computer includes an authentication server and one or more additional server applications resident thereon. The second computer, hosting the client application, has a remote object registry resident thereon. An object, referred to as a ticket and associated with the client application, is created and includes an acknowledgment method associated therewith. A unique identifier for the ticket and a stub associated with the ticket are registered in the client-side registry.
A communications link is established between the client application and authentication server. A command is transmitted from the client application to the authentication server to start the server application. The command is accompanied by an address for the client application and the unique ticket identifier. In response to transmitting the command to the authentication server to start the server application, the second computer receives from the first computer a stub associated with the server application. The received stub is then stored on the second computer in a location accessible to the client application. In response to receiving the stub, the ticket notifies the client application that the server application is ready to receive client application requests.
Operations for creating a ticket associated with the client application may include generating an identifier unique to the ticket, and registering the ticket in a client-side registry. The step of establishing a communications link between the client application and authentication server may include transmitting user identification information from the client application to the authentication server via the established communications link, and validating transmitted user identification information.
According to a server-side perspective of the present invention, the first computer receives, at an authentication server resident thereon, a command from the client application to start the server application, accompanied by an address for the client application and an identifier for a ticket registered with the client-side registry. In response to receiving the client application command to start the server application, the authentication server passes the client application address and ticket identifier to the server application. In response to receiving the client application address and ticket identifier from the authentication server, the server application retrieves from the second computer a stub associated with the ticket registered with the client-side registry. In response to retrieving the stub associated with the ticket registered with the client-side registry, the server application invokes the acknowledgment method associated with the ticket and passes a stub associated with the server application to the second computer.
The present invention is advantageous because, by moving a server-side registry to a computer hosting a client application (i.e., a xe2x80x9cclient-sidexe2x80x9d registry), a server application can notify a client application when server application startup processing is complete and can provide a server stub associated with the server application to the client application. As a result, a client application can be automatically notified that a server application is ready to receive client application requests. Consequently, the need for server polling may be eliminated.
Another benefit of the present invention is that failure of a client-side registry may disrupt processing only on the local machine hosting the registry. Other client applications accessing a server application may remain unaffected. In addition, by eliminating a centrally accessible server-side registry, security may be enhanced. Furthermore, object naming issues may be simplified since the only name exposed is the name of a ticket which is controlled by a client application. Servers, according to the present invention, are not dependent on, nor need to know, object naming structures.